For most of the last decade, the cobot safety conversation was really a fencing conversation. Power-and-force limiting under ISO/TS 15066 let you skip the cage, run a risk assessment, tune some torque thresholds, and move on. That logic still holds for a tabletop cobot doing light assembly at modest speed. It does not hold cleanly anymore for the current generation of higher-payload, higher-speed collaborative arms that vendors have spent the last cycle pushing into territory once reserved for fenced six-axis robots. When a cobot is moving real mass at real speed close to a person, and doing it in a cell that also contains a fixed robot and a couple of servo-driven gantry axes, the question stops being “do we need a barrier” and becomes “how do we prove the whole shared volume is safe, continuously, across every controller that has a hand in it.”
That second question is harder, and a lot of integrators are still answering it the old way — treating each machine’s safety system as its own island — when the actual risk lives in the interactions between islands.
Why power-and-force limiting alone stops being sufficient
ISO/TS 15066 gives you biomechanical limits — transient and quasi-static contact force and pressure thresholds by body region — and lets a cobot satisfy them through inherent design, speed and separation monitoring, or PFL. The math behind PFL assumes a certain relationship between mass, velocity, and contact geometry. As payload and speed both climb, satisfying those thresholds increasingly depends on active limiting — the controller actually slowing or stopping before or at contact — rather than the robot simply being incapable of hurting anyone at full speed. That’s a meaningfully different safety architecture. It means the cobot’s safety function is doing real work, continuously, and that function has to be validated to a discrete Performance Level, not just checked off as “the vendor says it’s collaborative.”
This is where a lot of risk assessments get sloppy. A collaborative rating on a datasheet is not a safety function. The safety function is whatever specific combination of speed limiting, force limiting, or zone-based stopping is actually configured for your application, at your payload, in your layout. Two integrations of the same cobot model can have completely different validated behavior depending on end-of-arm tooling mass, mounting orientation, and reach into shared space.
The real problem: whose safety controller owns the zone
Put that cobot in a cell with a fixed robot running on a Rockwell GuardLogix safety PLC and a servo axis or two under Siemens Safety Integrated drive-based monitoring, and you now have three safety architectures that each think they own a piece of the same physical volume. The cobot’s native safety controller enforces its own PFL and zone limits. The GuardLogix handles E-stops, light curtains, and interlocked guarding for the fixed robot. Safety Integrated is monitoring safe speed and safe position on the servo axes. None of those three systems was designed assuming the others exist.
The practical failure mode isn’t a dramatic one. It’s a gap: the cobot’s zone monitoring assumes the fixed robot’s reach envelope is static, but the fixed robot’s actual working envelope depends on a program branch nobody accounted for in the cobot’s risk assessment. Or the servo gantry has a safe-limited-speed function tied to a light curtain that doesn’t consider that the cobot has already reduced the effective clearance. Each subsystem is individually compliant. The cell is not.
A framework: three questions before you touch a PLC
Before deciding where safety logic lives, walk the cell through three questions, in this order:
- What is the actual shared hazard zone, dynamically, not statically? Map the reachable envelopes of every motion source — cobot, robot, servo axis — as they actually move in the real cycle, not their nameplate reach. Overlap zones are where your safety function requirements get set by the highest-risk contributor, not the average.
- What Performance Level does each function in that zone actually need? Run the risk assessment per ISO 12100 and ISO 10218/15066 for the collaborative interactions, and per ISO 13849-1 for the discrete safety functions (E-stop, muting, speed limiting, zone switching). A pinch point between a fast-moving fixed robot and a person doing manual load/unload usually lands at PLe. A cobot-only interaction that’s already speed-and-force limited may validate at PLd. Don’t assume; calculate the PL using the actual architecture (category, MTTFd, diagnostic coverage) for each function.
- Which controller is the single source of truth for the interlock between zones? This is the one integrators skip. Somebody has to own the boundary condition — the fact that cobot speed reduction and fixed-robot zone exclusion have to happen together, in a defined sequence, with a defined response time.
Where safety logic should live — and where it shouldn’t
The instinct is to centralize everything into one safety PLC and make it the arbiter. Resist that instinct for anything that’s already a validated, self-contained safety function inside a vendor’s controller. A cobot’s PFL behavior, tuned and certified by the OEM, should stay inside the cobot’s own safety controller — don’t try to re-implement force limiting logic in a GuardLogix or a TwinSAFE terminal just because you can. You’ll lose the vendor’s certification basis and inherit the validation burden yourself.
What belongs in a shared, higher-level safety controller is the coordination logic: zone arbitration, mutual exclusion between the cobot’s working envelope and the fixed robot’s, safe handoff signals, and the master E-stop topology that has to bring every subsystem to a safe state together. TwinSAFE, GuardLogix, and Safety Integrated all support safety-rated networking — TwinSAFE over EtherCAT with FSoE, GuardLogix via CIP Safety, Siemens via PROFIsafe — specifically so that discrete safety controllers can exchange safety-rated I/O without funneling everything through one PLC’s application logic. Use that. Let each vendor’s controller keep doing what it was certified to do, and use the safety network layer to pass zone-status and interlock signals between them, with the interconnecting logic itself validated as its own safety function with its own PL.
The validation step nobody wants to pay for
Once the architecture is right, you still have to validate the composite system, not just its parts. That means functional testing of the actual interaction sequences — cobot approaching the shared zone while the fixed robot is mid-cycle, servo axis moving while a person is in a collaborative interaction with the cobot — not just bench-testing each controller’s stop function in isolation. This is genuinely a multi-week effort on any cell with more than two motion sources, and it’s the step most commonly compressed or skipped when a project is behind schedule. It shouldn’t be. A PLe-rated E-stop that never gets exercised against the specific timing of a neighboring PLd zone switch isn’t actually PLe in practice — it’s PLe on paper.
What to actually do about it
If you’re integrating a higher-payload or higher-speed cobot into an existing multi-robot cell, don’t start with the cobot’s safety configuration. Start by drawing the dynamic overlap map, assign PLs per function based on the real risk assessment, and decide up front which controller arbitrates the boundary between zones. Keep each vendor’s certified safety function where it lives natively, and treat the interconnect as its own deliverable with its own test plan. The fence was never really the hard part. The zone always was — it’s just that faster, heavier cobots have finally made that impossible to ignore.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
